It has become a trend to offer and provide a vast range of new services in existing mobile networks and mobile communications systems. There is currently a very big interest in using mobile networks for multimedia or TV content. This is often referred to as Mobile-TV in the art. The goal for Mobile-TV applications is to offer a TV-like experience where the user can choose and easily zap between different multimedia or TV channels.
Ordinary TV channels are broadcasted to many users and typically the user can choose which channel to receive and view. Mobile-TV is similarly about delivering a set of (live) media or multimedia streams to several end-users. Each multimedia stream corresponds to a TV-channel, and each user shall be able to choose which channel to view. At the moment, broadcast/multicast delivery methods for Mobile-TV are under development. Examples of such standardisation efforts are 3GPP Multimedia Broadcast/Multicast Services (MBMS) and European Telecommunications Standards Institute (ETSI) Digital Video broadcasting-Handheld (DVB-H). These will be similar to traditional TV, in their broadcast distribution fashion.
IPTV (Internet Protocol TV) is a term used when delivering broadcasted TV-services over an IP network, typically a broadcast access network. In addition, more personalized service can be delivered due to the flexible nature of an IP network, e.g. video-on-demand or other user specific service, which then are delivered over unicast IP streams to the end user. IP video systems are becoming a key feature in service providers triple play offerings towards residential and business customers. Offering acceptable channel switching time with reasonable picture quality is essential for customers adoption. The problem maps directly into keeping low delays both in the customer premises and within the network.
To begin decoding and constructing an image from the video stream a lot of information needs to be gathered from the stream, which only comes with a certain frequency. In particular, to start displaying the image of a new video feed, the decoder needs to wait for a Random Access Point (RAP) to arrives in the video stream, a so called Intraframe or I-frame for older video standards, or a so called IDR (Instantaneous Decoder Refresh) for H.264. Such frames are the only frames in the media stream that contain enough information on themselves to reconstruct a complete image. They typically come with a periodicity of 0.5 to 5 seconds, depending on the encoding type.
Existing solutions use a combination of pull mechanisms to obtain the last intraframe transmitted in the video transmission (HTTP GET or other) from the video server or the closest access node, or different mechanism to deliver slightly time-shifted video streams, so that the time distance to receiving an intraframe gets heavily reduced. These solutions imply that the channel switching mechanism will only be able to show a static image until the next intraframe arrives and the video decoding can continue or that your bandwidth consumption grows with the number of time-shifted streams that you are making available at the access node (DSLAM or equivalent). If the time shifting occurs in the access node itself, the requirements on processing power and capabilities of the multiplexing access node gets greatly enhanced.
With the emergence of MBMS (Multimedia Broadcast/Multicast Service [1]) and DVB-H (Digital Video Broadcasting-Handheld, [2]), Mobile TV, which, in the beginning was entirely unicast, will consist of a combination of unicast and broadcast channels. This adds a new channel switching requirement as one need not only be able to switch between channels, but even between different transport sources of the same channel.
Unicast channel switching has been developed during a long period of time and methods of fast channel switching are available. When switching into a live channel, the media decoders typically do not instantly get all the information required to display the first complete picture of the video stream. It is only when decoding an Intra picture, a.k.a. key frame or Random Access Point (RAP) that the decoder can display a full picture. A good way of getting a fast and distinct channel switch is therefore that the media server buffers the bitstream and sends a delayed stream starting with a RAP to the decoder. In the case where RTSP (Real Time Streaming Protocol, [3]) the basis of PSS (Packet-switched Streaming Service, [4]) in 3GPP SA4) is used, this buffering can be used both when a completely new RTSP session is set up, and when the channel is switched inside an existing RTSP session.
In the case of switching channel inside an RTSP session, the switch can be done inside ongoing RTP sessions, or by establishing new RTP sessions, but the issue and solution remain the same.
A seamless transition between unicast and broadcast can be relatively simply achieved by simultaneously receiving the two streams during a short period and switching between the sources at an appropriate point. If the streams are identical on the packet level, it can be done on any packet. If not, the new stream should start to be decoded at a RAP. A prerequisite for this to work is that the difference in arrival time between the channels is small.
If the server buffers the unicast channels on an individual level to start sending a RAP, this leads to a delay whose maximal value is the distance between RAPs.
When switching from, for example, broadcast to unicast, but within the same channel, a fast switch to a buffered version of the channel starting with a RAP is not desired as this can result in a buffer under run, which will prohibit so called seamless access transition. That is, seamless in a user perceived sense of the word.
Thus, there is a need for methods and arrangement for enabling seamless transition to unicast sessions.